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(57) A protocol (20) for labeling various types of data 
contained in a music chip includes a hierarchical ar- 
rangement of headers (22, 34) for storing information 
about selections on the chip and the method in which 
they were coded in the memory of the chip. A global 
header (22) located at the very start of memory will spec- 
ify information needed to successfully decode the con- 
tent of the music chip. This will include, for example, the 
necessary bit rate (32), as well as information pertaining 
to a specific PAC (Perceptual Audio Coding) algorithm 
(30) employed in recording audio on the chip. In addition 
to the global header, each chip will have a section of 
memory (34) allocated to a table of contents. The table 
of contents will include information on play times (38), 
song titles (38), Music Category (40) and artist (42). In- 
dividual track selections (44) will be listed as part of the 
table of contents by individual headers. The individual 
header contains a music category to which a track be- 
longs, for example, classical, jazz, country, rock, etc., 
the artist, and information for addressing each track se- 
lection. Information from the headers is self-registered 
or automatically downloaded when a chip is loaded into 
a player/juke box device. The concept of self-registering 
general information included within the headers allows 
a user to select by type of music, artist, etc. for music 
selections made over a period of time. 
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Description 

FIELD OF THE INVENTION 



The present invention relates to a protocol for labe- 
ling various types of data contained in a music chip, and 
more particularly to a protocol that contains a hierarchi- 
cal arrangement of headers. 

BACKGROUND OF THE INVENTION 

A variety of recording media exist today for the stor- 
age of consumer directed pre-recorded music and other 
audio applications. These media include CD ROM 
(Compact Disc Read Only Memory ). DAT (Digital Audio 
Tape) and traditional magnetic cassette audio tape, just 
to name a few. Of the above technologies, the compact 
disc format has steadily increased in popularity and 
gained consumer approval due to the high sound quality 
of the digitally stored audio, as well as ease of use. 

Compact discs and other formats, however have 
some significant disadvantages. For one, compact discs 
do not normally include the ability to register the content 
of the information stored on disc prior to selection at the 
player. In other words, in order to gain any information 
regarding the contents of a particular music selection, 
that selection will first have to be manually selected at 
the player. In the alternative, some CD players may be 
manually programmed to play certain selections based 
upon user input. In either circumstance, however, there 
is no way to automatically search and play music by cat- 
egory, for example, by artist, music type, etc., unless a 
user has prior knowledge with regard to the selection. 
Such knowledge must include at a minimum the precise 
location of a selection on the recording medium, a way 
in which to direct the player apparatus to that location, 
and a searchable index keyed to the selection and the 
locations. Largely because of limitations in the recording 
medium, many of these functions cannot be accom- 
plished cost effectively or efficiently. It is therefore an 
object of the present invention, to provide a storage for- 
mat for pre-recorded music that is easily selectable by 
a user in regard to general content 

SUMMARY OF THE INVENTION 

The present invention is a protocol for labeling var- 
ious types of data contained in a music chip. The proto- 
col includes a hierarchical arrangement of headers for 
storing information about selections on the chip and the 
method in which they were coded in the memory of the 
chip. A global header located at the very start of memory 
will specify information needed to successfully decode 
the content of the music chip. This will include, for ex- 
ample, the necessary bit rate, as well as information per- 
taining to the specific encoding algorithm employed in 
recording audio on the chip. 

In addition to the global header, each chip will have 
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a section of memory allocated to a table of contents. The 
table of contents will include information on play times, 
song titles, music category and artist. Individual track 
selections will be listed as part of the table of contents 

5 by individual headers. The individual header contains a 
music category to which a track belongs, for example, 
classical, jazz, country, rock, etc., the artist, and infor- 
mation for addressing each track selection. Information 
from the headers is self-registered or automatically 

^0 downloaded when a chip is loaded into a player/juke box 
device. The concept of self-registering general informa- 
tion included within the headers allows a user to make 
selections by type of music, artist, etc. which is to be 
played over a period of time. 

IS 

BRIEF DESCRIPTION OF THE FIGURES 

For a better understanding of the present invention, 
reference may be had to the following description of ex- 
20 emplary embodiments thereof, considered in conjunc- 
tion with the accompanying drawings, in which; 

FIG. 1 shows a top plan view of one preferred em- 
bodiment of a music chip used in connection with 
^5 the present invention data protocol; 

FIG. 2 shows one preferred embodiment of the 
present invention data protocol utilizing a hierarchi- 
cal arrangement of headers; 

FIG. 3 shows one preferred implementation of an 
30 addressing scheme contained within individual 
headers; 

FIG. 4 shows another preferred implementation of 
an addressing scheme contained within the individ- 
ual headers. 

35 

DETAILED DESCRIPTION OF THE DRAWINGS 

Referring to FIG. 1, there is shown one preferred 
embodiment of a music chip 10, for use with the present 

40 invention data protocol format. The music chip 10 is es- 
sentially a memory component which is adapted to be 
received into an accompanying solid state audio player 
for playing music contained on the chip. The physical 
characteristics of the chip 10 are that of a device of ap- 

45 proximately 2.5" x 1 . 1 25" x 0.25" and made of a rugged 
ABS plastic (acrylic butyl styrene) or other like material. 
The relatively modest sized music chip device will have 
significant advantages over compact discs and other 
media with regard to transportability and storage. Mem- 

50 ory and interface circuitry of the chip 10 are embedded 
within the package. The memory of the music chip 10 
contains prerecorded music or other like audio material 
stored in a compressed digital format. 

Referring to FIG. 2, there is shown one preferred 

55 representation for the present invention memory config- 
uration and data protocol format 20 used with the music 
chip 10. The data protocol 20 is essentially a standard- 
ized format for obtaining addressing and music selec- 
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tion information stored on the music chip 1 0. Each music 
chip 10 is encoded with a global header 22 at a starting 
address of memory, presumably at address 0x0. The 
global header 22 contains general information about se- 
lections on the chip and the method in which they were 5 
coded, among other things. More specifically, the global 
header 22 will contain the distributor of the music 24, 
record label 26 and perhaps copyright information 28. 
This information will be displayable (and/or audible) on 
a display device associated with the audio player. Also ?o 
contained in the global header will be parameter infor- 
mation 30 that specifies the manner in which the music 
found on the chip 10 was encoded, i.e., the specific en- 
coding algorithm employed. 

The parameter information of the global header 22 ?5 
is advantageously included because as compression 
technology evolves, it may be possible to encode more 
on a single chip using different algorithms, and almost 
certainly at different bit rates. Thus, rather than "freeze" 
the compression algorithm to its current quality using a 20 
specific bit rate, it will be more cost effective to generate 
a specific algorithm release for each chip. This would 
allow an album from a specific artist introduced today to 
use 128 Kbps while an album released at some future 
date from the same artist could utilize a different algo- 25 
rithm that would play at perhaps 32 Kbps with the same 
quality that the 128 Kbps piece has at present. 

The global header 22, thus, will also specify the al- 
gorithm 30 and bit 32 rate needed to successfully de- 
code the contents of a music chip. By putting less than 30 
1 2K of information, for example, into this particular sec- 
tion of the global header, the present invention avoids 
stranding the hardware associated with the music chip 
to any particular software version. This versatility will al- 
low the memory size for a given play length to be re- 35 
duced over time, thus, providing a means to reduce the 
price per chip or increase margins. 

As mentioned, the global header 22 contains infor- 
mation about the selections on the chip and the manner 
in which they were coded. This and other header infor- 40 
mation are accessed once upon power-up or insertion 
of the music chip into an associated audio player in order 
to determine the available track selection of the chip. 
Header information pertaining to each track is read sub- 
sequently in cueing up the chip and navigating between 45 
individual track selections. 

In addition to the global header 22, each chip will 
have a section of memory therein allocated to what 
amounts to a table of contents 34. Track selections will 
be listed as part of this table of contents by individual so 
headers 36. The table of contents 34 will include infor- 
mation on play times, song titles, music category and 
artist. The information contained in the table of contents 
allows the chip contents to be self-registered, i.e., down- 
loaded, upon insertion into an audio player/juke box de- 55 
vice. 

Referring once again to FIG. 2, an exemplary rep- 
resentation for the table of contents 34 including individ- 



ual headers 36 is shown immediately following the glo- 
bal header 22. A preamble 38 is shown preceding the 
individual headers 36, wherein the preamble may in- 
clude play times and song titles as has been discussed. 
The preamble or global header may also include other 
information as memory costs prove to be less restrictive. 
Examples of additional information which may be includ- 
able on the memory chip include graphics data corre- 
sponding to the prerecorded music, such as album art- 
work, and printed song lyrics, each of which may be 
viewed on a display device associated with the audio 
player. The display device may be a display window on 
the player or a display at a remotely viewable device, 
such as a remote control. 

An individual header 36 is broken into sections and 
contains a music category 40. an artist 42, and address- 
ing information 44 for each track selection. The music 
category designates a type of music associated with 
each individual track, for example, classical, jazz, coun- 
try, rock, etc. The concept of storing specific track infor- 
mation within an individual header 36 allows a user to 
select music according to a categorized type of music, 
by artist, or combinations of both, as well as other crite- 
ria. For instance, a user may randomly select from the r ^ 
category of country western songs to be played over the 
course of an evening. On the other hand, the user could n 
also request to hear songs from a specific artist, for ex- f 
ample, Billy Joel. v 

The category section 40 (CAT) of the individual 
header 36 will correspond to a standardized numbering , 
scheme for types of music. The category section 40 in- ,4 
eludes a fixed field of predetermined length having some 
reasonable limit - for example, a field of eight binary , 
encoded bits corresponding to 256 possible categories. 
Examples of three letter abbreviations and correspond- 
ing category numbers for some standard music types 
are as follows: Classical (CLS:=0); Country (CTY-1); 
Gospel (GOS:=2); Jazz (JAZ=3); Popular (POP=4); Rap 
(RAP=5); Reggae (REG=6); Rhythm and Blues 
(RNB=7); and Rock (ROC=8). The list will, of course, be 
further developed to include various recognized music 
types. 

The specification of bit assignments to each music 
type is intended to be standardized and periodically re- 
viewed to accommodate new music types. Specification 
of the category codes and bit assignments therefor 
would most likely include input from music distributors, 
as well as the audio player hardware manufacturers. 

Also included within the individual header 36 is the 
artist field 42, which may be encoded in one of two dif- 
ferent ways. In a first technique, a unique bit assignment 
would be given to each recognized artist in a similar 
manner to the assignment of category codes 40. This 
method, however, will necessitate an extremely large 
field in order to include an almost boundless list of mu- 
sical artists. In addition, this coding technique will 
present a formidable challenge in keeping the artist en- 
codings up to date as new artists emerge. 
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A second approach, which is perhaps more effi- 
cient, is to implement a procedure for abbreviating an 
artist's name and then encode each character of the ab- 
breviation. As an example, an abbreviation for the artist 
Whitney Houston might be encoded as follows: 

EX; Whitney Houston —> WHOUST = 
23/8/15/21/1 9/20 

where alphabetic codes are represented as 
{8=1, b=2, c=3,.... z-26} Thus, each alphabetic charac- 
ter would be assigned a corresponding numeric code, 
wherein artist names would be abbreviated up to a pre- 
determined number of characters. The intent here is not 
to convey an absolute representation of the artist's 
name, but to provide a field that can be scanned quickly 
to identify selections from a particular artist with low 
probability of falsely selecting a track from another artist. 

This kind of encoding scheme, wherein the artist's 
name or identity is somehow abbreviated lends itself to 
arithmetic coding techniques used for text compression. 
Arithmetic coding, however requires a global database 
of possible artists to get the highest efficiency in bit as- 
signments and also results in non-uniform word fields. 
For this reason, arithmetic coding utilizing non-uniform 
word fields may be undesirable, since implementation 
thereof is contrary to the concept of fixed field widths. 
Non-arithmetically coded abbreviations, however, may 
be implementable utilizing a fixed field of sufficient 
length to accommodate abbreviations for any of the art- 
ists. 

As mentioned, an address field 44 is included as 
another section of the individual header 36. Two possi- 
ble encoding schemes are contemplated for the address 
field 44. Referring to FIG. 3, there is shown a first en- 
coding scheme 50 for indicating track addresses of a 
music selection. FIG. 3 shows the preamble field 38, as 
well as category and artist fields 40, 42. Addressing is 
accomplished by explicitly specifying a begin address 
(ADDRB) 52 and an end address (ADDRE) 54 for each 
track. These addresses are read from the individual 
header information 36 at the start of each track. Decod- 
ing of this first address encoding scheme 50 begins with 
ADDRB 52 and proceeds until ADDRE 54 is reached, 
at which time a new track is selected. The remainder of 
the memory in the music chip 10 following the global 
header 22 and individual header 36 information will con- 
tain the actual encoded music which is stored utilizing 
a suitable PAC algorithm. 

Referring to FIG. 4, a second address encoding 
scheme 60 is represented. As with the first approach 
shown in FIG. 3, the instant scheme utilizes the pream- 
ble 38, and includes an individual header with category 
and artist field 40, 42, respectively. An end address 62 
is specified following the artist field 42. The second 
scheme 60 relies more heavily on predefined, fixed 
width header fields and eliminates the need to specify 
both begin and end addresses (only one of which is sup- 
plied). Advantageously this is more efficient in terms of 
storage requirements and accessing time, since only 



one address need be accessed for each track. By utiliz- 
ing fixed field widths, the encoded music data corre- 
sponding to Track 1 of a music chip is known to begin 
at the end of the complete header information . i.e.. glo- 

s bal header 22 + preamble 38 + individual headers 36. 
Thus, the address field for Track 1 need only specify the 
end address 62, since the begin address is already 
known or implied. A begin address for subsequent 
tracks is computed as the end address 62 of the pre- 

TO ceding track on the chip, plus one address location, i.e.. 
one more than the end address of the preceding track. 

If a random play feature of tracks is desired, this can 
be achieved by indexing to the address field 62 of the 
appropriate header 36 of a preceding track and adding 

^5 one to recover a begin address for the desired track. 
The address field 62 for the last track on a music chip 
10 will be encoded with an "End-of-ROM" indicator in 
order to signify that no music content exists beyond that 
selection. 

20 It will of course be understood, that the address field 
62 of the present embodiment encoding scheme can al- 
so be equivalently encoded as the begin address of the 
next track, wherein the end address of the present track 
is implied. This approach is somewhat less intuitive than 

25 providing an end address, as previously discussed, in 
that the address information contained in a specific 
header does not explicitly pertain to the track in which it 
is encoded. 

The present invention data protocol for a music chip 
30 enables general information regarding specific music 
selections to be quickly and easily accessed. In a pre- 
ferred embodiment of the invention, the headers , i.e.. 
global and individual are encoded with fixed field widths 
to eliminate the need for explicitly numbering each track, 
35 The header information for a track, n, can then be ac- 
cessed at the following address: 

[global header width] + [(n-1) (individual header 
width)] 

where n= Track 1 , ... , Track N. 

40 By supplying general information regarding the con- 

tents of a music chip within a hierarchical arrangement 
of global and individual headers, this general informa- 
tion can be easily downloaded to a jukebox or home 
player, wherein a user may access that information with- 

^5 out having to manually program any hardware. Music 
selections are then easily accomplished on the basis of 
artist, type of music, or combinations of both, thus al- 
lowing for increased flexibility in the making of single or 
multiple music selections. 

50 Of course a significant concern in the implementa- 
tion of the present invention data protocol hierarchical 
header arrangement is the amount of memory space on 
the chip 1 0 which is lost in providing space for the head- 
ers. At present the standard music chip 10 includes in 

55 excess of 20 M-bytes of Read Only Memory (ROM). Em- 
ploying the encoding algorithm at present day process- 
ing speeds, this translates to approximately 45 minutes 
of usable playing time per chip. At an average of 3 min- 
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utes per track, a music chip can accommodate approx- 
imately 1 5 or more tracks. The memory required for stor- 
age of the 15 accompanying headers for each of the 
tracks is envisioned to be significantly less than 1% of 
the memory capacity of the music chip 10. Accordingly, 
the required memory space for storage of the header 
arrangement will not adversely affect the overall storage 
capacity of the music chip, and will at the same time pro- 
vide enhanced selectivity for the user 

From the above, it should be understood that the 
embodiments described, in regard to the drawings, are 
merely exemplary and that a person skilled in the art 
may make variations and modifications to the shown 
embodiments without departing from the spirit and 
scope of the invention. All such variations and modifica- 
tions are intended to be included within the scope of the 
invention as defined in the appended claims. 



6. The data format of Claim 1, wherein said second 
header includes addressing information corre- 
sponding to said individual tracks of audio. 

5 7. The data format of Claim 6, wherein said address- 
ing information includes a begin and end address 
for each of said individual tracks of audio. 



8, The data format of Claim 6, wherein said second 
10 header includes data fields of fixed widths, and 

wherein said addressing information includes only 
an end address for each of said individual tracks of 
audio, whereby a corresponding begin address is 
implied. 

15 

9. The data format of Claim 1 , wherein said first head- 
er includes data pertaining to distribution of said 
pre-recorded music. 



Claims 



20 



2. 



3. 



5. 



A data format for use in an audio system wherein 
pre-recorded music is digitally encoded in memory 
of an integrated circuit music chip, and said music 
is decoded and reproduced by means of an asso- 
ciated audio player, said data format for storing in- 
formation pertaining to the contents of said music 
chip, wherein individual tracks of audio are stored 
in designated locations in said music chip, said data 
format including: 

first header having parameters stored therein 
for use by said audio player in decoding said 
digitally encoded music stored in said memory; 
and 

at least one second header, said second head- 
er including selectable categorical information 
relating to said individual tracks of audio stored 
in said memory. 

The data format of Claim 1 , wherein said first head- 
er includes a bit rate used for decoding said con- 
tents of said memory. 

The data format of Claim 1 , wherein said first head- 
er specifies an algorithm used to encode said con- 
tents of said memory. 

The data format of Claim 1, wherein said second 
header includes a data field designating a category 
of music corresponding to one of said individual 
tracks of audio stored on said music chip. 

The data format of Claim 1, wherein said second 
header includes a data field having stored therein a 
code representative of an artist, said artist having a 
work included as a corresponding one of said indi- 
vidual tracks of audio. 
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10. The data format of Claim 5. wherein said code rep- 
resentative of said artist includes a binary coded ab- 
breviation of said artist. 

11. The data format of Claim 4, wherein said category 
code includes a binary code corresponding to a 
specific music type. 

12. The data format of Claim 1, wherein said at least 
one second header includes a data field corre- 
sponding to song titles and play times. 

1 3. The data format of Claim 4, wherein said music cat- 
egories are selected from the group consisting of 
Classical (CLS); Country (CTY); Gospel (GOS); 
Jazz (JAZ); Popular (POP); Rap (RAP); Reggae 
(REG); Rhythm and Blues (RNB); and Rock (ROC). 

14. The data format of Claim 1 , wherein information in- 
cluded in said first and second header is automati- 
cally downloadable from said music chip upon pow- 
er-up. 

15. The data format of Claim 1, wherein said at least 
one second header follows said first header and 
said second header includes a data field designat- 
ing a music category followed by a data field desig- 
nating a musical artist followed by a data field des- 
ignating addressing information for a corresponding 
one of said individual tracks of audio. 



16. The data format of Claim 15, wherein said address- 
ing information includes a begin and end address 
for each of said individual tracks of audio. 

55 17. The data format of Claim 15, wherein said second 
header includes data fields of fixed widths, and 
wherein said addressing information includes only 
an end address for each of said individual tracks of 
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audio, whereby a corresponding begin address is 
implied. 

1 8. A data protocol for use in storing pre-recorded audio 

in memory of an integrated circuit chip, said inte- s 
grated circuit chip being adapted for use with an au- 
dio player, said data protocol comprising: 

global header having parameters stored there- 
in corresponding to an encoding technique io 
used for storing said pre-recorded audio in 
memory and used by said audio player in de- 
coding said audio; and 

at least one individual header having multiple 
data fields, said data fields including general 75 
description information about individual tracks 
of said pre-recorded audio. 

19. The data protocol of Claim 18. wherein said global 
header specifies a bit rate to be used in decoding 20 
said pre-recorded audio stored in memory. 

20. The data protocol of Claim 1 8= wherein said individ- 
ual header includes a data field indicative of a music 
category for an associated track of audio. 25 

21 . The data protocol of Claim 1 8, wherein said individ- 
ual header includes a data field representative of an 
artist associated with said individual track. 

30 

22. The data protocol of Claim 18, wherein said individ- 
ual header includes addressing information for an 
associated one of said individual tracks. 

23. The data protocol of Claim 22, wherein said ad- 35 
dressing information includes only an end address 
and wherein a begin address is implied. 

24. The data protocol of Claim 18, wherein said global 
header and said individual header are self-regis- 40 
tered upon said integrated circuit chip being pow- 
ered in said audio player. 

25. The data protocol of Claim 18, wherein said pre-re- 
corded audio is encoded in memory immediately 45 
following said at least one individual header. 

26. The data protocol of Claim 18, wherein said at least 
one individual header follows said global header 
and said individual header includes a data field des- 50 
ignating a music category followed by a data field 
designating a musical artist followed by a data field 
designating addressing information for a corre- 
sponding one of said individual tracks of audio. 

55 

27. The data protocol of Claim 18, wherein said individ- 
ual header includes a preamble including displaya- 
ble information pertaining to song titles and play 



times therefor. 

28. The data protocol of Claim 18, wherein said individ- 
ual header includes a preamble including displaya- 
ble graphics relating to said prerecorded audio. 

29. The data protocol of Claim 18, wherein said individ- 
ual header includes displayable song lyrics. 

30. The data protocol of Claim 26, wherein said global 
header includes a bit rate used for decoding said 
prerecorded music, along with displayable record 
label and copyright information. 

31. A method of segmenting memory in an integrated 
circuit chip, said integrated circuit chip adapted for 
use in an audio player and said memory having pre- 
recorded audio stored therein, said method com- 
prising the steps of: 

storing in a global header parameters corre- 
sponding to encoding techniques used in stor- 
ing said pre-recorded audio in memory; and 
coding in at least one individual header data 
fields indicative of general description informa- 
tion for individual tracks of said pre-recorded 
audio. 

32. The method of Claim 31, further including the step 
of specifying in said global header a bit rate to be 
used in decoding said pre-recorded audio stored in 
memory. 

33. The method of Claim 31, wherein said individual 
header includes a data field indicative of a music 
category for an associated track of audio. 

34. The method of Claim 31, wherein said individual 
header includes a data field representative of an art- 
ist associated with one of said individual tracks. 

35. The data protocol of Claim 31 , wherein said individ- 
ual header includes addressing information for an 
associated one of said individual tracks. 
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(54) Data protocol for a music chip 



(57) A protocol (20) for labeling various types of data 
contained in a music chip includes a hierarchical ar- 
rangement of headers (22, 34) for storing information 
about selections on the chip and the method in which 
they were coded in the memory of the chip. A global 
header (22) located at the very start of memory will spec- 
ify infornnation needed to successfully decode the con- 
tent of the music chip. This will include, for example, the 
necessary bit rate (32), as well as information pertaining 
to a specific PAC (Perceptual Audio Coding) algorithm 
(30) employed in recording audio on the chip. In addition 
to the global header, each chip will have a section of 
memory (34) allocated to a table of contents. The table 



of contents will include information on play times (38), 
song titles (38), Music Category (40) and artist (42). In- 
dividual track selections (44) will be listed as part of the 
table of contents by individual headers. The individual 
header contains a music category to which a track be- 
longs, for example, classical, jazz, country, rock, etc., 
the artist, and information for addressing each track se- 
lection. Information from the headers is self-registered 
or automatically downloaded when a chip is loaded into 
a player/juke box device. The concept of self-registering 
general information included within the headers allows 
a user to select by type of music, artist, etc. for music 
selections made over a period of time. 
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